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EXPANSION BRIDGE APPARATUS AND METHOD 
FORANI^CBUS 

FIELD OF THE INVENTION 

The present invention relates generally to electronic equipment that 
communicates using the industry standard I^C (inter-IC control) bus. More particularly, 
the invention relates to an expansion device for use in. connection with such a bus. 

BACKGROUND OF THE INVENTION 

5 The use of I C (inter-IC control) devices is very popular among designers of 

electronic systems because the devices offer an inexpensive v^ay to provide distributed 
monitoring or control of a piece of equipment using a simple two wire serial 
communication bus. Inexpensive I^C devices are available to monitor voltage, 
temperature, and other physical quantities, provide non-volatile memory, parallel 10 

10 ports, and a large variety of other specialized functions. These devices are v^dely used in 
many types of electronic equipment from consumer electronics to computer systems. 

An I C bus provides for 128 unique addresses by definition. Real world designs, 
however, typically contain I^C devices that use multiple I^C addresses resulting in a 
practical limit of closer to 1-8 devices. Since only relatively few devices can be uniquely 

15 addressed on any given two wire I^C bus, designers typically use multiple I^C busses 
when the addresses on a given bus are used up. The use of multiple busses increases 
system cost and complexity. Another shortcoming of the I^C bus is that it does not 
provide any features to guarantee the integrity of the data that's traveling on the bus. 
Accordingly, there is a need for an I^C -type bus that practically supports a greater 

20 number of addresses while also providing an amount of integrity for data traveling 
thereon. 

SUMMARY OF THE INVENTION 

The present invention is an I^C (inter-IC control) bridge device which implements 
a communication protocol layered on top of a standai'd I^C protocol. The layered 
25 protocol used by the bridge device is termed the "La5^ered I^C Protocol" - abbreviated 
"LIP". Thus the bridge device is called a "LIP bridge device". The LIP bridge device 
provides I^C address extension, data integrity checking, and fault detection and isolation 
when inserted between an I^C bus master and it's intended target I^C device. Each LIP 



1 



Delmonico-1 



bridge device has at least two attached I^C busses - a parent bus and a child bus. The LIP 
bridge operates as a slave on its parent bus, and a master of its child bus. The Layered 
I C protocol is specified to operate on a bus between one or more bus masters and the 
parent bus of one or more LIP bridge devices. The child bus is used for attaching 
5 multiple I C devices and/or one or more LIP bridge devices. 

In an exemplary implementation, the LIP bridge device is constructed using a 
microcontroller to create a LIP bridge device with one parent and one child I^C bus port 
and a group of LIP bridge configuration pins. The pjirent bus traffic to a given LIP 
bridge device consists entirely of LIP packets, and the child bus traffic consists of 

10 standard I^C packets to communicate with standard child bus I^C devices. The child bus 
traffic may also consist of LIP packets to communic£tte with LIP bridges attached to the 
child bus. By design, the LIP packets and standard fc transactions do not interfere with 
one another. The LIP bridge device interprets LIP command packets from a bus master 
and translates them into the intended I^C data stream that is then broadcast over the child 

15 bus. Likewise, data firom the child bus is used to create LIP packets that are returned to 
the proper bus master. 

The use of LIP packets on a given I^C bus provides an extra level of I^C 
addressing. An I^C bus provides for 128 unique addiesses by definition. In many cases, 
real world designs, however, typically contain I^C devices that use multiple I^C addresses 

20 resulting in a practical limit of closer to 1 -8 devices. By contrast each LIP bridge device 
uses only one I C address and provides a child bus with 128 fi-ee addresses. Therefore 
LIP bridges expand the number of available addresses on the I^C bus from 128, to instead 
128 multiplied by the number of LIP bridge devices, which is a maxhnum of 
128x128-16384 I^C addresses. 

25 In one exemplary embodiment of the invention a first transceiver is coupled to a 

host bus master over a parent bus, where the host bus master uses a first communications 
protocol. A second transceiver is coupled to target devices over a child bus, the target 
devices utilizing a second communications protocol. The first protocol has a bridge 
device address field for addressing the bridge devices and a target device address field for 

30 addressing the target devices coupled to the child bus . The number of target devices 
addressable by the host bus master is expandable based on the number of bridge device 
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coupled thereto. A protocol translator is coupled to the first and second transceiver for 
translating communications in the first protocol destined for the target devices to the 
second protocol and translating communications in the second protocol destined for the 
bus master to the first protocol. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the present invention may be obtained from 
consideration of the following detailed description of the invention in conjunction with 
the drawing, with like elements referenced with like references, in which: 

FIG. 1 is a block diagram for one application of the present invention I^C bridge 

device; 

FIG. 2 is functional block diagram for one embodiment of the present invention 
I C bridge device; 

FIG. 3 is a block diagram for another application of the present invention I^C 
bridge device; 

FIG. 4 illustrates the basic command structure for a command fi-om the host bus 
master to the LIP bridge; 

FIG. 5 shows a detailed illustration of the LIP address hardware strapping; 

FIG. 6 shows a detailed illustration of the LIP address byte; 

FIG. 7 shows a detailed illustration of the child address/fimction byte; 

FIG. 8 shows a detailed illustration of the read count field byte; 

FIG. 9 shows a detailed illustration of the read data tag byte; 

FIG. 10 shows a detailed illustration for an exemplary embodiment of the status 
byte register; 

FIGS, 11-16 show exemplary transaction structures for selected commands 
generated from the host bus master to LIP; 

FIGS. 17-18 show pinouts for exemplary microcontrollers used to implement the 
present invention I^C bridge device; 

FIGS. 19-21 show exemplary data flows for various levels of firmware used in 
connection with the I^C bridge; and 
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FIG. 22 shows an exemplary embodiment for an expansion bridge using an 
alternate parent bus. 

DETAILED DESCRIPTION 

The present invention is an I^C (inter-IC control) bridge device which implements 
5 a communication protocol layered on top of a standard I^C protocol. The layered 
protocol used by the bridge device is termed the "Layered I^C Protocol" - abbreviated 
"LIP", Thus the bridge device is called a "LIP bridge device". The LIP bridge device 
provides I C address extension, data integrity checking, and fault detection and isolation 
when inserted between an I^C bus master and it's intended target I^C device. Referring to 

10 Fig. 1 , an illustration of a typical usage of the LIP bridge device 1 0 is shown. Each LIP 
bridge device has at least two attached I^C busses - a parent bus 12 and a child bus 14. 
The LIP bridge device 10 can have more than one child bus or parent bus port. The LIP 
bridge 10 operates as a slave on its parent bus 12, and a master of its child bus 14. The 
Layered I C protocol is specified to operate on a bus between one or more bus masters 16 

15 and the parent bus of one or more LIP bridge devices. The child bus 14 is used for 

attaching multiple I^C devices 18 and/or one or more LIP bridge devices 10. As shown, 
the LIP bridge devices can also be cascaded. 

In an exemplary implementation, the LIP bridge device 10 is constructed using a 
microcontroller to create a LIP bridge device with one parent and one child I^C bus port 

20 and a group of LIP bridge configuration pins. The pairent bus traffic to a given LIP 
bridge device consists entirely of LIP packets, and the child bus traffic consists of 
standard I^C packets to communicate with standard child bus I^C devices. As will be 
explained, the child bus traffic may also consist of LIP packets to communicate with LIP 
bridges attached to the child bus. By design, the LIP packets and standard I^C 

25 transactions do not interfere with one another. The LIP bridge device interprets LIP 

command packets fi:om a bus master and translates them into the intended I^C data stream 
that is then broadcast over the child bus. Likewise, data from the child bus is used to 
create LIP packets that are returned to the proper bus master. 

The use of LIP packets on a given I^C bus provides an extra level of I^C 

30 addressing. An I^C bus provides for 128 unique addresses by definition. In many cases, 
real world designs, however, typically contain I^C devices that use multiple I^C addresses 
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resulting in a practical limit of closer to 1-8 devices. By contrast each LIP bridge device 
uses only one I^C address and provides a child bus with 128 free addresses. Therefore 
LIP bridges expand the number of available addresses on the I^C bus from 128, to instead 
128 multiplied by the number of LIP bridge devices, which is a maximum of 
5 128x128=16384 I^C addresses. 

Referring to Fig. 2, a high level fimctional block diagram of a LIP bridge 
device 10 is shown. The bridge device 10 couples to the LIP bus 12 via an LIP bus 
transceiver 20. This I^C transceiver is an I^C slave only, and responds to LIP packets 
addressed to the LIP bridge from a Host I^C Bus Master 16 (Fig. 1). The I^C bus master 

10 is typically an intelligent device, e.g., a microprocessor, that is responsible for gathering 
data and providing control via the commands issued and received o the LIP bus. The I^C 
transceiver 20 can also function as a slave transmitter so that the Host I^C Bus Master 16 
can extract data from the LIP bridge 10. In the incoming direction the bus transceiver 20 
couples to a CRC (cyclical redundancy check) generator and checker 22 which calculates 

15 a CRC code for any incoming or outgoing LIP packets. As is well known, a CRC code is 
a xmique number that is related to the data in a mathematical way such that even a single 
bit change in the data will result in a different CRC code. 

A bridge read engine 24 is activated by the LIP bus I^C transceiver 20 when a 
Host I^C Bus Master 16 wishes to extract data from the LIP bridge 10. If data is 

20 available it is tagged with information to identify the intended receiver, the data, and 
length. This is followed by a CRC check code so that the Host I^C Bus Master 16 can 
verify that the data was not corrupted during transmission. If no data is available, the 
bridge read engine generates a packet signifying to the Host I^C Bus Master 16 that there 
was no data available. Outgoing LIP packet FIFOs 28, 29 accumulate data from requests 

25 made to the LIP bridge 10 until the requesting Host f'C Bus Master 16 reads the data 
from the LIP bridge. There can be one or more such FIFOs, e.g., one for each Host I^C 
Bus Master. Although only one host bus master is required, additional benefits may be 
realized in system configurations including two or more I^C Bus Masters. In such 
configurations, data tagging and the ability to recover data obtained but transmitted 

30 unsuccessfully due to, for example, multi-master interference, become valuable. 
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An incoming LIP packet FIFO 30 accumulates incoming LIP packets for 
processing by a LIP packet parser and dispatch function 32. The LIP packet parser and 
dispatch mechanism 32 removes LIP packets from the Incoming LIP Packet FIFO 30, 
and verifies that the packet passed the CRC check. It then verifies the packet contents are 
5 a valid command and verifies that the entire packet was received within a specified time 
window. If all tests pass, then the command is forwarded to a command engine 36 or 52 
for processing. If any tests fail, the packet is discarded and an error logged. Data from 
the LIP packet parser and dispatch is provided to a command collision detection unit 38 . 
The command collision detection unit 38 determines if multiple Host I^C Bus 

10 Masters 1 6 have pending commands that will result in the potential for a given master 
receiving the wrong data. In this case, a special packet is retumed for all Host I^C Bus 
Master reads until the collision condition is clear. The packet informs all involved Host 
I^C Bus Masters 16 that their data is available, and can be obtained via a retry. An error 
logger 40 receives error signals from all relevant fimctional units, and writes the data in a 

15 standard format to an intemal error log 41 . Error data is preserved until it is read out by a 
Host I^C Bus Master, then explicitly cleared. A LIP bridge global reset unit 42 is 
responsible for resetting the entire state of the LIP bridge device 10 when requested. It 
can also render the bridge inoperative and tri-state all outputs - in case the LIP bridge has 
an intemal failure and must be isolated so that a partner LIP bridge can fimction in its 

20 place. The LIP bridge global reset unit 42 receives inputs from three sources: a global 
watchdog timer 44, a LIP supply voltage monitor 46, and an incoming partner reset-in 
signal line 48. All three of these sources can cause a reset of the LIP bridge 10. In 
addition, if the partner reset-in signal line 48 is held asserted, it will render the LIP bridge 
inoperative and electrically inert by tri-stating all outputs. 

25 The global watchdog timer 44 signals the LIP bridge global reset unit 42 if any 

fimctional unit within the LIP bridge fails to check in at a regular interval. This allows 
potential recovery from transient errors. The LIP supply voltage monitor 46 will signal 
the LIP bridge global reset unit 42 if the power supplied to the LIP bridge falls below a 
certain threshold. An event watchdog timer 48 is used by several fimctional units to time 

30 a given operation. 
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A child bus I C transceiver 50 functions as an I C master only on the child bus 14. 
It sends data to and receives data ftom I^C targets 1 8 attached to the child bus in response 
to commands from the child bus command engine 36. The child bus command engine 36 
receives commands from the LIP packet parser and dispatch unit 32 to send data to or 
5 extract data from a given child bus I^C target and relays the request to the child bus I^C 
transceiver 50. In the case of a child bus read operation, all data received is placed into 
the respective outgoing LIP Packet FIFO 28, 29. If the read v^as unsuccessfial according 
to the child bus I C transceiver 50, then a formatted error packet is placed into the 
appropriate outgoing LIP packet FIFO 28, 29. A special fimction command engine 
10 receives commands from the LIP packet parser and dispatch imit 32. An extensive list of 
commands exists to retry operations, read and clear error log entries, query the status of 
the LIP bridge, perform intemal tests, and modify operational characteristics of the LIP 
bridge. Some of these commands place data into an appropriate outgoing LIP Packet 
FIFO 28, 29. 

15 LIP Protocol 

A unique protocol is utilized in accordance v^ith the present invention between a 
host bus master, the PC busses to which the host bus masters is connected, and target LIP 
bridges. The LIP bridges are the target ofthe messages from the host bus master. The 
host bus master and LIP bridges utilize LIP to communicate. LIP bridges provide 

20 electrical PC isolation, PC address extension, and data integrity enhancement. The 
electrical isolation that LIP bridges supply between tlie host bus master busses and the 
actual child PC busses enhances overall reliability of a system. 

As mentioned, the LIP bridge supports a slave-only parent bus and a master-only 
child bus. In an exemplary embodiment, the parent bus is handled by high performance 

25 dedicated PC hardware within the LIP bridge microcontroller, and child bus 

communication is done using a firmware PC driver v/ith hardware assistance from the 
LIP bridge microcontroller. Altemately, communication on both busses could be 
implemented utilizing high performance hardware, or for lower cost and performance 
communication on both busses can be implemented predominately in firmware. 

30 In another exemplary application of the present invention shown in Fig. 3, the 

host bus master 1 16 is the PC master of A and B busses 1 12, 113, where two busses are 
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utilized to provide increased data integrity. These busses make use of LIP messages, 
where each of these busses is connected to one or more LIP bridges 110 which act as PC 
slaves. Each LIP bridge 1 10 has a unique programmable PC address selected by pin 
strapping on the LIP bridge device. Every LIP bridge is the PC master of the single child 
5 bus 1 14 to which it is connected. One or more PC devices 1 18 are attached to the child 
bus 1 14, and standard PC protocol is used to communicate to them. Bridge cross resets 
are used to enhance reliability by allowing each LIP bridge to reset and/or tri-state the 
other bridge 

An understanding of PC communication is helpful to understanding the Layered 
10 PC Protocol, since LIP is layered on standard PC protocol. A description of the I2C 

protocol is included in "The I^C-Bus Specification" Version 2.0, December 1998, Philips 
Semiconductor, Version 2.1, January 2000 and "The I^C-bus and how to use it" April 
1995, Philips Semiconductor, which are available at 

http://ww-us2.semiconductors.philips.coin/acrobat/various/I2C BUS SPECIFICATION 2.pdf. 

15 the entire content of the documents being incorporated by reference herein. 

All communication between a host bus master 116 and a LIP bridge 110 takes 
place using the Layered PC Protocol. Although LIP communication is bi-directional, the 
host bus master is always master and initiates all communication with the LIP bridge. 
Thus the host bus master 1 16 (in a manner similar to traditional I^C protocol) provides 

20 serial clock and data signals when transmitting to the LIP bridge (master transmitter), and 
(as master receiver) a clock for receiving messages fi*om the LIP bridge. The LIP bridge 
therefore functions as an PC slave when receiving data or slave transmitter when 
returning data to a host bus master. Thus, it is understood that the parent bus has the 
same operational characteristics as that of the standaid PC two wire bus. 

25 Writing data from the PC master (always the host bus master) to the PC slave 

(always the LIP bridge) is initiated and carried to completion by the PC master. 
Typically, the master asserts an PC start on the bus, followed by a slave address with the 
write bit set. If the slave acknowledges receipt of the address, then the master can send 
one or more data bytes to the slave. Reception of each data byte must be acknowledged 

30 by the slave. A successful transaction is complete when the master asserts an PC stop on 
the PC bus. 
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When the master (host bus master) needs to read data from the slave (LIP bridge), 
the host bus master first writes a command to the LIP bridge to request the desired type 
and quantity of data the host bus master wishes to read. The master can then begin the 
read transaction. The read is initiated with an PC start, followed by the slave (LIP 

5 bridge) address with the read bit set. After the LIP bridge slave acknowledges the 
[address + 'R'] byte, the host bus master is designated a master-receiver, and the LIP 
bridge slave becomes a slave-transmitter. The master then clocks data out of the slave a 
byte at a time, until the slave has supplied the number of bytes requested by the master. 
After the master receives each byte, the master must provide an acknowledge bit to the 

10 slave on the ninth clock pulse. This is normally done automatically by the host bus 
master's hardware PC transceiver. The transaction is completed when the master 
purposely signals a no-acknowledge for the last data byte it receives, and then asserts an 
PC stop condition on the bus. 

In the exemplary embodiment of the invention, a master write command from the 

15 host bus master to the LIP bridge has a four byte fonnat 120 as shown in Fig. 4. Each 
request to the LIP bridge will consist of exactly four bytes. A LIP Address 122, a Child 
address / Function field 124, followed by one byte (data to write or a count field for 
reads) 126, and finally a CRC 128 for the packet. 

Every packet sent to the LIP bridge must be four bytes in length. Packets which 

20 are not exactly four bytes in length are discarded, and an error is logged. The LIP bridge 
marks the end of a packet by sensing a start or stop on the PC bus. The packet is 
discarded and an error is logged if a packet is shorter than four bytes and is not completed 
within a time out period or if a new packet is sent before the previous packet is complete. 
The LIP bridge can retum from one to fifteen bytes of data to the host bus master 

25 during a read operation plus one additional byte which is the CRC byte for the data read. 
If the master continues to read data past the number of bytes requested in the read count 
field (plus one more byte of CRC), then the LIP bridge will retum the extra bytes as valid 
CRC values. If the master terminates the read transaction (by no-acknowledging a byte) 
before 'read count' bytes (plus the CRC byte) are read, then an "UNREAD_DISC" error 

30 will be logged and the remaining data will be discarded. Once the host bus master begins 
reading data from the LIP bridge, the host bus master has a fixed time period to clock all 
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the data for the read transaction out of the LIP bridge. After the fixed time period, an 
"SLV_XMT_TIMEOUT" error will be logged, and the remaining data will be 
discarded. 

Each LIP bridge responds to a unique PC address configured by strapping pins on 

5 the LIP bridge device. As will be explained herein, tm exemplary bridge device will 
typically be incorporated within the context of a microcontroller. Other possible 
embodiments could include incorporation an ASIC. Moreover, the hardware requirement 
is small enough that the LIP bridge could occupy a reasonably small portion of a large 
system ASIC, Alternately, the LIP bridge could use a small fraction of the resources of a 

10 system's main processor (such as in a personal computer or an industrial controller). 
The hardware address strapping 130 will be assigned as shown in Fig. 5. The LIP 
address byte 122 (Fig, 6) identifies which LIP bridge the command packet is destined, 
and whether the packet describes a read or a write command. Thus there are seven bits 
available for addressing LIP bridges. The PC protocol does not allow for address data 

15 protection on the bus. However, transmitted addresses are protected by the packet CRC, 
If the address field of the packet is corrupted, and that causes it to arrive at the wrong LIP 
bridge, then the LIP bridge accepting the packet will ignore the packet and log an error 
due to an invalid packet CRC, The LIP bridge device will have seven pins available for 
address strapping (plus one address parity pin to mat:e odd parity), allowing up to 128 

20 LIP bridges per bus. The strapping pins A0-A6 will correspond to bits 1-7 respectively in 
the LIP address 122 (see Fig. 6). On the parent bus during transactions, bit 0 is a 
Read/Write function bit pertaining to the LIP bridge addresses, in accordance v^th 
standard I^C protocol. In one exemplary embodiment, the LIP bridge will not fimction if 
the address strapping does not produce odd parity. This parity protection will normally 

25 prevent LIP bridge address contention on the LIP bus. Should multiple strapping errors 
defeat this mechanism, then the CRC protection on each packet will prevent data 
corruption in case two LIP bridges are responding to the same address. Ultimately, the 
CRC protection will allow the host bus master to detect the contention fault. 

Referring to Fig. 7, it can be seen that the Child Address / Function byte 124 can 

30 be used for one of two purposes. As a child bus address, this byte can be used to cause an 
address cycle on the child bus to begin a read or write transaction to a target on the child 
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bus. All transactions on the child bus begin with an PC start followed by a child address. 
Because of the variety of target PC devices and resulting transactions, the PC child 
address may be followed by reading or writing to the target. The type of transaction 
(read or write) is determined by bit zero of the child address. The number of bytes 
5 written to or read from a child bus PC target may vaiy depending on the target device and 
the transaction type. 

Secondly, if the Child Address field 124 is specified as binary '1 1 1 1.1 1 Ix' (OxFF 
or OxFE), then the entire packet is interpreted as a special function. Special functions are 
used to query the LIP bridge or perform specific LIP bridge operations. In the 

10 embodiment of Fig. 4, the low bit is used to identify the host bus master that is requesting 
the special function command. If the low bit is '0' tlie command is being requested by 
host bus masterO, and if the bit is ' T the conmiand is requested by host bus masterl . The 
value of this bit is set by the requesting host bus master, passed through the LIP bridge, 
and returned in a "Read Data Tag" byte 132 (Fig. 9) if appropriate. For special function 

15 commands that return data to the host bus master, this allows the requesting host bus 

master to verify that the data it is reading is actually iintended for it. The use of this bit by 
the host bus master is equivalent to the "SrcId" field of the Read Count byte sent during 
child bus read commands, (See Fig. 8.) 

Still referring to Fig. 7, the Child Address field 124 specifies whether the child 

20 will be written to or read from. If the transaction is a 'write' then the "write data" field 
126 is the data written to the child. The LIP bridge does not interpret this data - it is 
simply passed through. It is up to the master to issue the proper number of data bytes in 
the correct sequence to perform a desired operation on the child bus PC target. 

The host bus master can perform single byte ^^tes to an PC target on the child 

25 bus by sending one packet to the LIP bridge. The foior-byte packet will contain the child 
address 124 and the write data 126. If a multiple byte write is not currently in progress, 
the LIP bridge will initiate an PC start on the child bus, transmit the child address and 
write data, and issue a stop on the PC child bus. Single byte writes are useful for simple 
devices such as byte wide PC lO expanders. 

30 Some PC targets on the child bus require multiple bytes of data from the host bus 

master to perform common operations. The LIP bridge supports writing multiple bytes to 
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a child bus target as follows. The host bus master must: 1) issue the "CHILD_ I2C 
_START" special function command to directly cause an PC start on the child bus; 2) 
issue the desired number of single byte write packets to the intended child bus target; 
since an PC start was explicitly forced by host bus master, these write packets do not 

5 generate start cycles on the child bus, and only the first packet causes an address to be 
sent out on the child bus and 3) issue the "CHILD_ I2C _STOP" special function 
command to directly cause an PC stop on the child bus, or issue a write with a child 
address field different from the first data packet. 

If not explicitly requested by the host bus master, a stop will automatically be 

10 issued on the child bus by the LIP bridge if during a multiple byte write the LIP bridge 
receives a packet from host bus master with a differeat child bus target PC address field. 

As shown in Fig. 8, if the transaction is a child bus read, then the second byte 126 
is a count field which specifies how many bytes the host bus master wishes to receive. 
This count field can specify from one to fifteen bytes inclusive. A count of zero or 

15 greater than 15 will cause the command to be ignored, and an error will be logged. The 
"RdCnt" field is six bits wide to allow for a possible future increase in read packet 
lengths. The "SrcId" field is a one-bit identification tag that the LIP bridge returns to the 
host bus master when the host bus master ultimately reads the child bus data. When 
submitting a child bus read request, host bus masterO should clear this bit, and host bus 

20 master 1 should set this bit to ' T. 

Referring to Fig. 9, it is illustrated that during a LIP bridge read by the host bus 
master, the LIP bridge returns a "Read Data Tag" byte 132 to the host bus master before 
actual data is returned. This is done to help a given host bus master verify that the 
incoming data belongs to it, is the quantity expected, and is valid data. The data 

25 indicated by reference numeral 1 30 is retumed to the host bus master as a response to the 
LIP bridge read. The "Read Data Tag" byte consists of three fields. The RdCnt field 134 
is the amoxmt of data the LIP bridge is ready to return to the host bus master. This 
amount may differ from the "RdCnt" amoxmt requested in the original child bus read 
command. The SrcId field value 136 comes from the original host bus master child bus 

30 read (or special function command) request and is '0' for host bus masterO, and ' T for 
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host bus masterl. The NoData field 138 indicates if there is data available for the LIP 
bridge read. 



Table 1- summarizes how to interpret the "Read Data Tag" byte. 



NoData 


Srcid 


RdCnt 


Interpretation (and recovery) 


1 


X 


0 


The LIP bridge is responding to a LIP bridge read that 
was not expected, or potentially, the origmal request for 
the data was corrupt so that no data is available for a LIP 
bridge read. The entire transaction should be retried. 


1 


X 


NonO 


The LIP bridge was unable to obtain data from the Child bus for the 
host bus master's read rec^uest due to a child bus error. The SMC can 
check the LIP bridge status byte to determine if there was a child bus 
error or a LIP protocol violation. The entire transaction should be 
retried. 


0 


X 


1-15 


The LIP bridge obtained RdCnt bytes for the host bus master's child 
bus read request. The bytes can be read from the LIP bridge along 
with the CRC. Data will be available for the 
"R_LAST_CHILD_DATA_x" command should the SMC need to 
retry the LIP bridge read,, 

If the SMC detects that tlie SrcID field is incorrect, then it has 
accidentally snatched the other host bus master's data. The correct 
data can likely be obtained by issuing the appropriate 
"R_LAST_CHILD_DATA__x" command. If that command results 
in a "no-data" return frora the LIP bridge, the entire transaction 
should be retried. 


0 


X 


0 


The LIP bridge is responding to a LIP bridge read during a multiple 
SMC read command collision. "RdCnt" field of zero indicates that 
all data read by SMC for this transaction will be random (invalid) 
with a valid CRC. The data can be recovered with the appropriate 
"R_LAST_CHILD_DATA_x" cmd, after a staggered timed back 
off to avoid another conflict 



The child bus read command is sent by the host bus master to define the type and 
quantity of data the host bus master wishes to receive from the LIP bridge. Although all 
commands sent to the LIP bridge from the host bus master are a fixed length of four 
bytes, the quantity of data returned \o the host bus master during a LIP bridge read is the 
quantity the host bus master reads out based on the read request - and can thus vary. To 
receive the data the host bus master must begin a new transaction on the LIP bus which 
consists of an PC start, followed by the LIP address byte with the R/! W bit set (to 
indicate a read operation). The host bus master can then read the data it previously 
requested from the LIP bridge. The return data will consist of a "Read Data Tag" byte 
132, followed by the amount of data 140 specified in the RdCnt field 134 of the "Read 
Data Tag" byte, plus one CRC byte 142. 
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There is a subset of commands that can not be issued between the child bus read 
command (or special function command prefixed by "RJO sent to the LIP bridge and the 
actual reading of the data (via a LIP bridge read). This restricted subset includes all 
commands in Table 1 prefixed by "R_", and child bus read requests. The set of safe 
5 commands that can be issued during a pending child bus read request include child bus 
write requests and various LIP bridge maintenance commands. Issuing any one of the 
restricted commands has a different effect depending on the source requester, A host bus 
master may also be referred to as a system master controller (SMC). 



Table 2 



Command N 


Command N+1 


Result 


SMCx: 

Child bus read or 

special lUQC/LlOn 

command 
prefixed by "rJ'. 


SMCx: 

child bus read or special 
function command 
prefixed by "R_". 


The data for Command N is discarded in favor of the 
data for command N+1 . A SNG_RD_CNFLT error is 
logged. The next LIP bridge read will return data for 
command N+1. 


SMCx: 

Child bus read or 
special function 
command prefixed 
by"R_". 


SMCy: 

child bus read or special 
function command 
prefixed by "RJ'. 


Commands N and N+1 are both honored and executed. 
No error is logged for the collision. When SMCx and 
SMCy perform a LIP bridge read to extract their data; 

1 . The reads are treated as unexpected returning a 
"Read Data Tag" of '0'. The data stream returned 
will consist of a random seed followed by a stream 
of bytes for which the last byte will be valid CRC 
for tiie previous bytes. 

2. SMCx and SMCy must perform a timed back off 
to ensvure no new child bus read or special function 
commjmd prefixed by "R_" is performed until all 
outstanding data is fully recovered. 

3 . SMCx and SMCy can recover their requested data 
by executing a R_LST_CHILD_DATA__IDn 
command, so long as no new commands overwrite 
the data. If the data is overwritten, an 
"UNREAD DISC" error is logged. 



10 

Beginning with the "Read Data Tag" byte and followed by all bytes from the 
target child PC device, the LIP bridge will accumulate a CRC for the read transfer. The 
CRC is accumulated for the total number of bytes requested in the read command or for 
15 as many bytes as the child bus transfer continues, in case the child bus transfer is aborted 
before completion. 
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In a similar fashion the LIP bridge will accun-Lulate a CRC for the data requested 
by any special function command which returns data to the host bus master, including the 
"Read Data Tag" byte. The LIP bridge makes all calculated CRCs available for 
immediate transmission following the last data byte. The host bus master must read one 

5 byte beyond the last requested data byte to obtain the CRC. If the host bus master fails to 
read the CRC byte (by terminating the read transaction before clocking out the CRC) the 
LIP bridge will log an "UNREAD^DISC" error. The CRC can be obtained until it is 
overwritten by a new CRC. 

In case a LIP bridge detects a hard fault on the child bus, any child bus read 

10 transaction will return the "Read Data Tag" byte indicating an error, followed by a stream 
of random data bytes to the host bus master (length equal to the length requested in the 
original read request), and a valid CRC byte. This behavior will insure that the host bus 
master detects an error condition. The LIP bridge will not retry the failed child bus read 
operation. 

15 Every four-byte packet to the LIP bridge concludes with a CRC byte. This byte is 

calculated on the first three bytes of the packet using a CRC algorithm. The LIP bridge 
verifies that the CRC sent by the host bus master matches the CRC it calculates for the 
received data. If a mismatch between the CRCs is detected, the packet is ignored, and a 
"BAD__CRC JN" error is logged. 

20 The host bus master can detect a missing LIP bridge easily. LIP bridge presence 

detection is best done immediately foUovring a LIP bridge or system reset event to avoid 
misinterpreting an input queue overflow condition as a missing LIP bridge. If the host 
bus master transmits a LIP address on the LIP bus and that address byte is followed by a 
no-acknowledge, then there is no LIP bridge responding to that LIP address. If the LIP 

25 address is followed by an acknowledge, then a LIP bridge is present and responding to 
that LIP address. 

The LIP bridge has an input queue for accepting packets from the host bus master. 
This queue has a limited depth. If the host bus master should fill the queue by 
transmitting packets faster than the LIP bridge can process them, then the LIP bridge will 
30 signal a queue full condition by no-acknowledging the LIP address and issuing no- 
acknowledge' s for each byte the host bus master sends after the LIP address. This no- 
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acknowledge signal will continue for all bytes the host bus master attempts to send to the 
LIP bridge until the LIP bridge has had time to clear some of the input queue. The LIP 
bridge will log an "input queue full" error. The host bus master can continue re-sending 
the packet's bytes after a short delay. 

5 The LIP bridge saves the data portion of the last master write packet received 

from the host bus master. The host bus master can read back this data if desired. If after 
receiving a packet the LIP bridge detects a CRC mismatch with the received CRC, the 
packet is ignored, and an error is logged. The host bus master can query the LIP bridge 
for the status and/or the last data sent to the LIP bridge if there is suspicion of a problem. 

10 LIP bus errors can be caused by momentary electrical disturbances from hot-plug 

events, or more serious problems such as failing hardware. The LIP bus is a two wire 
serial bus that electrically meets the PC electrical specifications. The simplicity of the 
PC low level protocol limits the number of errors that can happen on the bus to: 1) faults 
which cause one of the two bus wires to remain stuck at a logic level and 2) transient 

15 errors on the bus wires which corrupt a byte or address in transit on the bus. The errors hi 
the first case are detectable by the host bus master. The LIP bridge fimctions as a slave to 
the host bus master and so can't reasonably detect such errors. Transient errors can affect 
both the host bus master and the LIP bridge. 

The LIP bridge and the protocol itself are designed to provide electrical isolation, 

20 address extension, and data integrity enhancement by bridging the LIP bus and the 

attached child bus. The LIP bridge has no knowledge of the purpose of the data passed 
through it, and therefore the LIP bridge is incapable of detecting errors that involve more 
than one packet. The LIP bridge can only detect errors within a single master write 
packet from host bus master. When the host bus master is reading data from the LIP 

25 bridge (with the LIP bridge fimctioning as a slave transmitter) the host bus master will be 
able to detect LIP bus errors using the CRC supplied by the LIP bridge. Table 3 below 
lists high level LIP bus errors and recovery actions. 



Table 3 



Error Type 


Error Outcome 


Recovery Action by host bus master 


host bus master write 
to LIP bridge with 
corrupted four-byte 
command packet. 


Packet CRC mismatch detected in LIP 
bridge, packet is ignored in LIP bridge, 
LIP bridge logs an error. 


host bus master ultimately discovers discrepancy 
via cross checking or via reading LIP bridge error 
log. host bus master either retries operation or uses 
data from other LIP bridge. 
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Portion of multi-byte 
host bus master write 
to LIP bridge 
corrupted. 


Packet CRC mismatch detected in LIP 
bridge, packet is ignored in LIP bridge, 
LIP bridge logs an error. 


After completing all master writes to LIP bridge 
associated with multi-byte child bus write, the host 
bus; master reads the LIP bridge error log and notes 
one or more errors, host bus master must reissue 
multi-byte transaction. 


hnst bus master 
receives data from 
LIP bridge as slave 
transmitter, data 
stream is corrupted. 


As a slave transmitter LIP bridge can't 
detect this type of error. 


Upon receiving all data, host bus master determines 
via cross check or by checking CRC for received 
data that the data is corrupt, host bus master can 
issue R_LAST_CHILD_DATA command to 
recover data from a child bus target, or in the case 
of icorrupt data from a special function command - 
reissue the command. 



Child Bus Arbitration 

The LIP bridge is the master of the child bus it is attached to. Because in the 

5 exemplary implementation of Fig. 4, there are two LIP bridges 1 10 connected to each 
child bus 1 14, they must arbitrate for the child bus when there is a need to communicate 
with a child bus target 118. The procedure for arbitration is defined in the PC 
specification and is used by the LIP bridge. Following the PC specification in this area 
guarantees there will be no PC contention on the child bus. If the two LIP bridges 

10 receive commands from the host bus master which require use of the child bus, then each 
LIP bridge will arbitrate for the bus, and one will win. When the bus is free following the 
completion of the child bus transaction, the LIP bridge which lost arbitration can try to 
arbitrate again. There is no priority in arbitration so each LIP bridge has an equal 
opportunity to win the arbitration. 

15 An interesting property of PC occtirs when two LIP masters simultaneously start 

the exact same transaction on the same child bus to the same child bus target. In this case 
it is possible that the transaction will proceed on both LIP bridges in lockstep - with each 
LIP bridge thinking that it is the master for the transaction. Because of data and clock 
OR'ing, and the rules of data and clock toggling, this is perfectly allowable and will not 

20 degrade signal mtegrity or performance on the bus. It has the side benefit of guaranteeing 
that the host bus master will see identical data firom the child bus since it was read only 
once from the source. 

Special Fimction Commands 

Special Fxmction commands are used to cause the LIP bridge to perform a specific 
25 action or return to the host bus master requested data.. Special functions are provided for 



17 



Delmonico-1 



verification of data validity and other pxirposes. There are several different classes of 
special function commands. For example, special function commands include commands 
neither requiring nor returning data. These commands perform a simple action v^ithin the 
bridge or on the child bus. Also included are commands that return data to the host bus 
5 master on a subsequent master read of the LIP bridge. These commands typically 

provide LIP bridge internal information or status to tlie host bus master. In Table 4, these 
commands are prefixed by "RJ'. In addition, special function commands are commands 
that require data from the host bus master before being invoked. In Table 4, these 
commands are prefixed by "W_". 

10 Table 4 



Special Function 


Hex 
Command 
Code 


Comments 


Reserved 


0x00 


Reserved command 


R_I2C_ADDR 


0x01 


Returns one b;^e PC address that LIP bridge is strapped to in hardware. The 
host bus master can use this command to verify that it is communicating 
with the LIP bridge it attempted to address and there are no address 
collisions. 


R_TEST_PATT 


0x03 


Returns test pattern of OxAA. The host bus master can use this command to 
verify access to the LIP bus. 


R STATUS 


0x05 


Returns LIP status byte 


R_VERSION 


0x07 


Returns one b;^e LIP version number. This number should be used by host 
bus master to track LIP capabilities. 


R LIP ERRLOG 


0x09 


Returns error log for LIP bus 


R CHILD ERRLOG 


OxOB 


Returns error log for child bus 


R_LAST„DATA_BYTE 


OxOD 


Return last "write data" field from command packet. Returns one byte - last 
data sent. 


R_LAST_CRC 


OxOF 


Return last callculated CRC. Returns one byte. 


R_DUMP_LIP_RAM 


0x11 


Returns all LIP memory bytes from address 0-191. This is for diagnostic or 
error logging purposes only. 


R_LST_CHILD_DATA_IDO 


0x13 


Return all datii LIP bridge gathered from last child bus read command issued 
by source ID 0. 


R„LST_CHILD_DATA_ID1 


0x15 


Return all datii LIP bridge gathered from last child bus read command issued 
by source ID I. 


CLEAR_CHILD_ERRLOG 


0x02 


Rearm and clear error data from child bus error log. Also updates LIP status 
byte. 


CLEAR_LIP_ERRLOG 


0x04 


Rearm and clear error data from LIP bus error log. 
Also updates ILIP status byte. 


CHILD_I2C_START 


0x06 


Perform PC s1:art on child bus. 
Used to initiate multi-byte write. 


CHILD_I2C_STOP 


0x08 


Perform PC stop on child bus. 
Used to end multi-byte write. 


ENABLE_BAD_CRC 


OxOA 


Cause all calculated CRC's returned to host bus master to be incorrect. 
Mode stays enabled for all transactions until mode is disabled again. This is 
for diagnostic purposes only. 


DISABLE_BAD_CRC 


OxOC 


Send correct CRC data to host bus master for all transactions. This is the 
power on / resiet default. 


RESET_LIP_SELF 


OxOE 


Reset this LIP' bridge. 


RESET_LIP_PARTNER 


0x10 


Reset partner LIP bridge. 
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HOLDRST„LIP_PARTNER 


0x12 


Assert then hold partner LIP bridge in reset. The partner LIP bridge will be 
held in reset IPartner reset can be released by issuing a 
RESET_LIP_ PARTNER conunand. This command is useful in case the 
host bus maste;r suspects that the partner LIP bridge has gone bad, and needs 
to be held off iJie child PC and LIP busses. 


NOP 


0x14 


Does nothing. During transmission by the host bus master, the LIP bridge 
will acknowledge each byte of the packet. Upon successful reception of a 
valid NOP command, the command is ignored. No state within ttie LIP 
bridge is changed. This command is mtended to provide a method for the 
host bus master to detect that a LIP bridge is present, without the need to 
read data back from the LIP bridge (as with R_TEST_PATT, etc.), A 
BAD_CRC_IN error will be logged if the CRC is bad for NOP conmiand 
packet. 


Reserved for future use. 


0x14, 0x16, 
0xl7-xFF 





LIP Bridge Status Byte 

Referring to Fig. 10, the LIP bridge status byte 150 contains a one byte summary 
of the most important aspects of LIP bridge health. The host bus master has read only 
access to this status byte. Following any type of LIP bridge reset or power cycle, the 

5 value of all status bits within the byte is zero. Status Bit Descriptions are as follows: 
RAZ - "read as zero" indicates a bit reserved for future use that will return a zero if read. 
CBRE - Child Bus Read Error indicates the LIP bridge has detected and logged an error 
on its child bus during a read operation to a child bus. target by the LIP bridge. The first 
error that occurs is logged and locked in the child bus error log. The details of the error 

10 can be obtained by issuing the "R_CHILD_ERRLOG" special function command. 
Issuing the "CLEAR_CHILD_ERRLOG" command will clear and rearm the error log, 
and also this status bit. CBWE - Child Bus Write Error, The LIP bridge has detected and 
logged an error on its child bus during a write operation by the LIP bridge to a child bus 
target. The first error that occurs is logged and locked in the child bus error log. The 

15 details of the error can be obtained by issuing the "R_CHILD__ERRLOG" special 

function command. Issuing the "CLEAR_CHILD_ERRLOG" command will clear and 
rearm the error log, and also this status bit. LBRE - LIP Bus Read Error indicates the LIP 
bridge has detected and logged an error on the LIP bus during a read from the LIP bridge 
by the host bus master. The first error that occurs is logged and locked in the LIP bus 

20 error log. The details of the error can be obtained by issuing the "R_LIP_ERRLOG" 
special function command. Issuing the "CLEAR__L[P_ERRLOG" command will clear 
and rearm the error log, and also this status bit, LBM^ - LIP Bus write Error indicates 
the LIP bridge has detected and logged an error on tlie LIP bus during a write to the LIP 
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bridge by the host bus master. The first error that occurs is logged and locked in the LIP 
bus error log. The details of the error can be obtained by issuing the "R_LIP_ERRLOG" 
special function command. Issuing the "CLEAR_LIP_ERRLOG" command will clear 
and rearm the error log, and also this status bit. ME - Multiple errors bit indicates that the 
5 LIP bridge has encoxmtered more than one instance of one or more of the error types, and 
so some amount of error history will be available via the "R_LIP_ERRLOG" and 
"R_CfflLD_ERRLOG" commands. The ME bit will automatically clear when both error 
logs are cleared. 

LIP Bridge Error Logs 

10 Table 5 illustrates an exemplary structure that is returned in response to the host 

bus master requesting error information for the LIP bus or the child bus. One structure is 
maintained for the LIP bus, and one for the child bus. The log's data bytes are sent in the 
numbered order given below. All fields are cleared by executing the "rearm and clear 
error" command for a given bus. If any logged error fields contain error data (and are 

15 thus locked against any changes), then a clear operation will rearm them to accumulate 
errors again. The table lists the byte ordering, an abbreviation for the error log field, and 
a description of the data in the field. 



Table 5 



Order 


Name 


Description 


1 


NUM_ERR 


Number of errors accumulated following a "rearm and clear error" command for 
a particular bus (child or LIP), or any type of LIP bridge reset. 


2 


W_ERR1 


Error code for first latched error associated with a master write operation to tiie 
bus. 


3 


W„ERR1_CA 


Child bus address (if any) associated with first latched write error, or zero if a 
child bus address was not involved. 


4 


W3RR1_CMD 


Special ftmction command code or child bus "Read Data Tag" associated witii 
first latched write error. 


5 


R_ERR1 


Error code for first latched error associated with a master read operation fi"om 
the bus. 


6 


R__ERR1_CA 


Child bus address (if any) associat<5d with first latched read error, or zero if a 
child bus address was not involved. 


7 


R_ERR1_,CMD 


Special function command code or child bus "Read Data Tag" associated with 
first latched read error. 


8 


ERR2 


Second latched error code. 


9 


ERR3 


Third latched error code. 
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LIP Bridge Error Codes 

The LIP bus and the LIP bridge's child bus eaich have a dedicated error log with 
the structure given in Table 5, and error codes in Tables 6 and 7. After the first error is 
stored, that part of the error log is locked from further change and one or more bits are set 
in the "LIP bridge status byte" as appropriate. Following the initial error of a given type 
(read or write) there is space in the error log for two additional errors codes. These are 
used to log an error code if the initial error log entry of a given type (read or write) is full. 
This allows for logging one read and/or one write error plus two more error codes for the 
each bus. When all entries in an error log are filled, subsequent error information will be 
lost. Any error will cause the appropriate bit in the LIP bridge status byte to be set and 
locked. Error data is entirely cleared in a given error log by executing the appropriate 
clear command for the error log. The clear command also rearms the error log to receive 
data again, and clears the appropriate bit (or bits) in the LIP status register. Note that LIP 
bus errors and general LIP bridge errors fall into the numerical range of 0x1-0x80, while 
child bus errors are numbered fi-om 0x80-0xFF. This allows the two types of errors to be 
distinguished in the ERR2 and ERR3 fields of the eiTor log. 

Table 6 



LIP Bus Errors 



NO ERROR 


0x00 


No Error present 


BAD_CMD 


0x01 


Command written to LIP bridge did not consist of correct four byte packet. Command was 
ignored. 


BAD_READ_CNT 


0x02 


Invalid *read count' field in a read command packet. The 'read count' field was outside the range 
of 1-15 bytes inclusive. 


BAD CRC IN 


0x03 


CRC check failed on incoming conamand, command was ignored. 


QUEUE_FULL 


0x04 


Input queue full, LIP bridge aclcnowledged LIP address and then no-acknowledged subsequent 
incoming data bytes. 


RCV_TIMEOUT 


0x05 


Receive tuneout. The time betkveen the reception of the LIP address to the reception of the fourth 
command byte exceeded time limit Command was ignored. 


WATCHDOG_RST 


0x06 


Watch dog reset. An internal error occurred in the LIP bridge which caused the watch dog timer 
to hard reset the LIP bridge. All internal state has been reset, a stop has been issued to the child 
bus, and any commands in process have been lost. 


INTERNAL ERR 


0x07 


Internal error. An unspecified internal error has occurred within the LIP bridge. 


UNREAD^DISC 


0x08 


Unread data discarded. The host bus master read less data from the LIP bridge than it requested in 
the 'read count' field of the command packet and/or failed to read the extra CRC byte, by 
terminating the read transaction early with a no-acknowledge on a data byte from the LIP bridge. 
The remaining data and/or CRC are discarded. 


READ^OVERRUN 


0x09 


Read overrun error. The host t(us master read more data from the LIP bridge than it requested as 
part of a read or special fimction command. The extra data is returned as random data with a valid 
CRC. 


BROWN_RESET 


OxOA 


Brown Out reset. A drop in sujpply voltage caused the LIP bridge to reset. 


RSVD_CMD_ERR 


OxOB 


Reserved command error, the host bus master requested execution of a special function 
command with a reserved command code. The command was ignored. 
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DUMP_INCOMP 


OxOC 


RAM Dump incomplete. The LIP bridge was unable to return all 192 bytes of RAM to the host 
bus master following a DUMP_LIP_RAM command. Either the host bus master no- 
acknowledged the data before fiilly sent, or the transaction took longer than 50mS. 


XMT_TIMEOUT 


OxOD 


Slave transmission timeout. The time elapsed since the host bus master clocked out the first byte 
of data during a LIP bridge read exceeded the bridge slave transmit time-out before the CRC byte 
was clocked out, indicating an incomplete LIP bridge read. 






Single host bus master Read Conflict. A single given host bus master issued two consecutive 
commands to the LIP bridge (and mix of child bus read or special function command prefixed by 
"R ") before reading the data from the first command. 




OxOF 


Multiple host bus master Read (Ilonflict, host bus masterx issued a child bus read or special 
fiinction command prefixed by "R_", and before host bus masterx performed a LIP bridge Read to 
extract the data, host bus masteiy issued a child bus read or special function command prefixed by 
"R 


UNEXPECTED_RD 


0x10 


The LIP bridge received a LIP bridge read when there was no data available for transmission to 
the host bus master. This could occur if the original read request was corrupted or otherwise lost 
or dropped, resulting in no data available for the subsequent LIP bridge read. 




0x11- 
0x80 


Reserved 



Table 7 



Child Bus errors 



CHILD_SCL_SL 


0x81 


PC clock line stuck at logical zero. This is a hardware fault, or possibly a long 
glitch from a hot plug event. 


CHILD_SCL_SH 


0x82 


PC clock line stuck at logical one. This is a hardware fault, or possibly a long 
glitch from a hot plug event. 


CfflLD_SDA_SL 


0x83 


re data line stuck at logical zero. This is a hardware fault, or possibly a long 
glitch from a hot plug event. 


CHILD__SDA_SH 


0x84 


PC data Ime stuck at logical one. This is a hardware fault, or possibly a long 
glitch from a hot plug event. 


CHILD ADDR NOACK 


0x85 


No response from PC target (no-acknowledge from address cycle) 


CHILD DATA NOACK 


0x86 


Target no-acknowledged data transfer. 


CHILD_ARB_ERR 


0x87 


LIP bridge could not obtam access to the child bus from the other LIP bridge. 




0x88-0xff 


Reserved 



5 



CRC Algorithm 

A CRC Algorithm is used to calculate all CRC's within the LIP bridge. It is a 
property of the CRC algorithm that if the last byte processed is the transmitted CRC, then 
the resulting calculated CRC will always be zero if there has been no transmission error. 
10 Any non-zero value would indicate a transmission eiTor. The algorithm is capable of 
detecting: 1) any odd number of errors anywhere within the packet (i.e. -1,3,5,7. .. bit 
errors), 2) all double-bit errors anywhere within packet, 3) any cluster of errors that can 
be contained within an 8-bit "window" (1-8 bits incorrect) and 4) most larger clusters of 
errors. 

15 The CRC calculation can be represented by a linear shift register with feedback 

taps given by the polynomial X ^+ X V X 1 . This can be implemented in software by a 
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loop construct or a table lookup. The loop implementation produces compact code (about 
20 instructions), but uses about 150 machine cycles to execute. The table implementation 
uses more code space (300 bytes or more) but is much faster (perhaps 10-20 machine 
cycles). Consult "Technical Aspects Of Data Communication, Third Edition, 
5 McNamara" for theory and implementation of several different types of CRC algorithms 
and further references on CRC's in general 

Exemplary Transactions 

Now that the basic structure of the LIP bridge device and its accompanying 
protocol have been described, the foUov^ng illustrates some typical transactions between 

10 the host bus master and the LIP bridge. The byte ordering in the packets below is first 
byte to last byte fi-om left to right. Within each byte, the bits are ordered MSB to LSB 
from left to right. In all of the transaction samples, note that the "acknowledge / no- 
acknowledge" bit is provided by the PC interface hai'dware automatically. In fact, for 
most hardware implementations, it is not possible to modify or prevent the proper use of 

15 this bit. It is shown in the transactions for completeness. 

Fig. 1 1 illustrates a host bus master to LIP One Byte Child Bus Write 160 and Table 6 
illustrates the symbol key for Figs. 1 1 - 16. The host bus master uses this transaction to issue a 
one-byte write to a target on the child PC bus. This transaction is useful for writing to any PC 
target requiring one byte, such as a byte wide PC parallel expander. This transaction will cause 

20 the following sequence on the child bus: 

1 . Arbitrate for child bus 

2. PC start 

3. Address the PC device on the child bus specified by the child address 

4. Write the data from the data field 
25 5. PC stop 

Note that the child bus is not released by the LIP bridge until the entire transaction is 
complete. The transaction may cause any of the following errors to be logged: 1)LIP 
errors - Bad command, CRC check failed, receive tiimeout, input queue full and 2) Child 
errors - All 

30 Fig. 12 illustrates a host bus master to LIP Multi-Byte Write 1 62. The host bus 

master can use this transaction to issue one or more bytes of writes to a target on the child 

23 



Delmonico-1 



PC bus. Any number of bytes (greater than one) can be sent to a child bus target this 
way, assuming the target device will accept them. This command is useful for child bus 
PC targets requiring more than one byte, such as 16 bit parallel PC expanders, and 
EEPROM devices. 

5 If it is essential for the data to arrive at the PC target on the child bus intact, the 

host bus master can check the LIP status byte after the transmission to insure the 
transaction was error free. Reading back the data sent between data packets will interrupt 
this transaction, and should not be done. This transaction will cause the following 
sequence on the child bus: 

10 1 . Arbitrate for child bus 

2. PC start 

3. Address the PC device on the child bus specified by the child address 

4. Write the data from the data field of subsequent single byte write packets until the CA 
field no longer matches that of the first single byte write packet. 

15 5. PC stop 

Note that the child bus is not released by the LIP bridge until the entire transaction is 
complete. 

The transaction may cause any of the following errors to be logged: 1)LIP errors - 
Bad command, CRC check failed, receive timeout, input queue fiiU, reserved command 
20 error and 2) Child errors - All 

Fig. 13 illustrates a Special Function Action Neither Requiring Nor Returning Data 164. 
The host bus master uses this transaction to invoke a special ftinction action that neither requires 
nor returns data. Execution of commands that perform an action can be verified by reading the LIP 
status byte. The LIP status byte will indicate if there are any errors latched. Some examples of 
25 this command type are: CLEAR_LIP_ERRLOG, CLEAR_CHILD_ERRLOG, 

CHILD_I2C_START,CHILD_I2C_STOP,AllENABLE_, DISABLE^ commands, and all 
RESET_ commands. 

The transaction may cause any of the following errors to be logged: 1) LIP errors 
- Bad command, CRC check failed, receive timeout, mput queue full, reserved command 
30 error and 2) Child errors - PC bus stuck-at errors. 

Fig. 14 illustrates a Special Function Action Returning Data 166. The host bus 
master uses this transaction to invoke a special function action that retums data. 
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Explicitly verifying execution of these commands is not necessary, since they return data. 
Failure to return data would be the failure indicator, however any errors encountered by 
the LIP bridge are logged. All such commands are prefixed by "R_" in Table 1. Some 
examples of such a command: R_VERSION, R_STATUS, 
5 R_LST_CHILD_DATA_IDO (returns multiple bytes), R_LIP_ERRLOG, 
R_CHILD_ERRLOG (returns multiple bytes). 

When issuing the special function request, the issuing host bus master identifies 
itself to the LIP bridge via the low bit of the Child Bus address / Special function field. 
This identification is passed through the LIP bridge, and returned to the host bus master 
10 as part ofthe "Read Data Tag". 

The host bus master should clock out the "Read Data Tag" byte, followed by the 
number of data bytes that the requested special function command provides, plus one 
CRC byte. The special function will provide one or more bytes of data dependmg on the 
requested command. If the host bus master continues to clock data out past the proper 
1 5 amount, then each extra data byte returned will be valid CRC for the previous bytes, and 
a "READ_OVERRUN" error will be logged. Note that the host bus master can check 
tiie "Read Data Tag" field to verify that the data it is receiving was actually intended for 
it by checking the "Srcid" bit. Additionally, the "RdCnt" field can be used to fiirther 
identify the read transaction. If the "NoData" bit is set then there is no data available for 
20 this read transaction, and the R_LST_CHILD_DATA_ron command can not be used 
for recovery. This could be the resvilt of a child bus error. 

The transaction may cause any of the following errors to be logged: LIP errors - 
Bad command, CRC check failed, receive timeout, input queue full, unread data 
discarded, read overrun, reserved command error 
25 Fig. 15 illustrates a Special Function Action Requiring Data 168. The host bus 

master uses this transaction to invoke a special function action that requkes data. This 
capability is provided for possible future use, it is currently not a part ofthe exemplary 
embodiment. The transaction may cause any of the following errors to be logged: 1) LIP 
errors - 111 formed command, CRC check failed. Receive timeout and 2) special function 
30 errors - Reserved command error 
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Fig. 16 illustrates a host bus master Child Bus Read Via LIP Bridge Action. The 
host bus master should use this transaction to read data from a child bus VK: target. Any 
preparation of child bus PC target for a read operation must be done before the child bus 
read is requested. For example, if the child bus PC larget is a particular address within 

5 an EEPROM device, then the appropriate commands for setting the EEPROM address 
must be sent before the read transaction is requested. 

Following transmission of the child bus read request, the host bus master must 
perform a LIP bridge read. The host bus master should clock out the "Read Data Tag" 
byte, followed by the number of data bytes specified in the RdCnt field, plus one CRC 

10 byte. This can be from three to seventeen bytes inclusive. If the host bus master 

continues to clock data out past tiie proper amount, tlien the extra bytes returned will be 
valid CRCs, and a "READ_OVERRUN" error will be logged. Note that the host bus 
master can check the "Read Data Tag" field to verify that the data it is receiving was 
actually intended for it by checking the "SrcId" bit. Additionally, the "RdCnt" field can 

15 be used to further identify the read transaction. If the "NoData" bit is set then there is no 
data available for this read transaction, and the R_LST_CHILD_DATA_IDn command 
can not be used for recovery. This could be the result of a child bus error. 

This transaction will cause the following sequence on the child bus: 
1. PC start. 

20 2. Address the PC device on the child bus specifie(][ by the child address and request a 
"read" transaction type. 

3. Read data from tiie child bus PC device until the count specified in the Read Count 
field is reached, or until an error prevents further reading. 

4. PC stop. 

25 The transaction may cause any of the following errors to be logged: 1) LIP errors 

- Bad command, CRC check failed, receive timeout, input queue fiill. Unread Data 
Discarded, Read Overrun, bad read coimt and 2) CMld Bus Errors - All. 

LIP Bridge Microcontroller 

The LIP bridge can be implemented usmg one of several microcontrollers, for 
30 example, those made by Microchip Technology Inc. There are several devices which are 
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optimal for LIP bridge use. These devices have a hai dware I^C interface that will 
facilitate excellent performance. Exemplary microcontrollers 180, 182 with their 
associated pin outs are shown in Figs. 17-18. 

Referring to Figs. 19 -21, in connection with Fig. 2, a design overview of some of 

5 the basic firmware required to implement the I^C bridge device is shown. Fig. 22, for 
instance shows a flow diagram 190 for the packet haiadler 191 and associated devices 
which couple between the LIP bus and child bus. Fig. 23 illustrates data flows 192 for 
the packet parser 193 and its associated devices. Fig. 24 illustrates the I^C data flows 194 
between the packet handler 195 and child bus 196. 

10 The LIP bridge of the present invention overcomes a shortcoming of I C in an 

environment where there are muUiple I^C bus masters accessing one or more slave 
targets. In this environment, when two bus masters attempt to read data from the same 
slave target, it is impossible for the slave to know which I^C master is performing the 
read operation. There are many instances when this can result in a given I C master 

15 receiving data intended for another I^C master, which can cause significant problems. 
The LIP bridge tags all data waiting to be read so theit a given I^C master can verify that 
the incoming data is intended for it, or if not to discard the data and retry the operation. 

Whenever a LIP bridge device is inserted between an I^C master and it's target 
I^C device(s), the LIP bridge device provides fault detection and isolation capabilities 

20 that result in a solution v^th greater reliability. For example, consider two designs: 

A. I^C master connected to 64 target I^C devices wWch monitor eight equipment bays. 

B. I^C master connected to 8 LIP bridge devices (one per equipment bay), with each LIP 
bridge connected the eight target I^C devices in m equipment bay. 

Consider any of the foUovdng common faults that could occur: 

25 1 . Target I^C device fails, and renders I^C bus unusable. 

2, An electrical connector, wiring, or power fault in an equipment bay causes bay failure 
and renders the child side I^C bus unusable. 

3. The equipment is exposed to electrical interference, causing corruption of data 
flovdng to and from the I^C master. 

30 If faults one or two occxirred, design "A" would completely fail, while design "B" 

could continue to function at a reduced capacity due to the ability to detect then isolate 
the failiire behind a LIP bridge device. If fault three occurred, design "A" would 
completely fail, while design "B" would continue to operate by making use of the data 
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integrity checking. If data integrity checks were frequently failing, the equipment's 
operator could be notified to rectify the problem. 

To provide a high availability solution, each LIP bridge device has hardware and 
firmware features that allow it to self-monitor it's own operation and take corrective 
5 action when possible or at least report potential problems. In addition, availability is 
greatly enhanced with the ability to partner a LIP bridge device with a second LIP bridge 
device to serve the same master and set of target I^C devices. Partnering LIP bridges 
provides redundancy in case of LIP bridge failure, and takes advantage of partnering 
signals so that each LIP bridge device can reset or disable the other LIP bridge device to 
10 isolate it in case of failure. Partnering additionally allows the host to cross check data 
provided by the partner LIP bridge, as a technique to virtually guarantee data integrity. 

The LIP bridge device invention solves several problems inherent in the use of 
I^C busses. The device: 

1 . Expands the number of I^C addresses available on a single level I^C bus by a factor of 
15 128. Cascading LIP bridges into multilevel busses expands available addresses by 

128*128. 

2. Provides data integrity checking, data transmission reliability, and correct recipient 
guarantee. 

3. Identifies data during read operations so that the requester can verify it is receiving 
20 the correct data. 

4. Provides high availability and fault detection and isolation, 

5 . Provides the ability to partner LIP bridges to add hardware redundancy for extremely 
high availability and confidence in data integrity. 

25 For many computer systems (including PC's and especially servers), 

communication/network equipment (switches, routers, etc), office machines, and 
industrial machines - the customer values the equipment's ability to monitor and report 
faults or be managed and controlled remotely even if the equipment is unattended or even 
locked away. Designers must provide an inexpensive method of supplying these 

30 competitive features that ensures data integrity and is itself a reliable component. The 
invention meets these goals by allowing the use of inexpensive I^C devices to provide 
monitoring and control functions over a single cost effective I^C bus, while achieving 
high availability and guaranteed data integrity. 
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In addition, the use of I^C which uses a serial clock an data line as a transmission 
medium is not required, and this technology could be implemented on another 
information bus such as RS232, RS485, SPI, etc. Am illustration of such an arrangement 
is shown in Fig. 22. Fig. 22 shows an RS232/RS485 bus master 210 which couples to an 

5 appropriate RS232/RS485 LIP bridge 212 through a LIP serial bus 214 carrying LIP 
protocol over an RS232 or RS485 electrical medium rather than I^C. RS485 and RS422 
in particular, can be used over longer distances, compared to I^C. Target devices 216 are 
coupled to the bridge device 212 over an I^C bus 21 8 in the manner previously described. 
The foregoing description merely illustrates the principles of the invention. It will 

10 thus be appreciated that those skilled in the art will be able to devise various 

arrangements, which, although not explicitly described or shown herein, embody the 
principles of the invention, and are included within its spirit and scope. For example in 
certain high precision, low fault tolerant applications, the host bus master performs every 
child bus read operation on two different LIP bridges to ensure data integrity of the LIP 

15 bridge. Also, a LIP bridge can include more than one parent bus or child bus ports. 
Multiple child busses can allow greater economy with a reduction in redundancy - for 
instance, the accessing of more I^C addresses per dollar. In addition, multiple parent 
busses utilized with one child bus allow the bridging of two systems together while 
providing all the benefits of an individual bridge. An example of such an application is 

20 remote management capability by two servers of a large disk drive rack. Furthermore, all 
examples and conditional language recited are principally intended expressly to be only 
for instructive purposes to aid the reader in understanding the principles of the invention 
and the concepts contributed by the inventor to furthering the art, and are to be construed 
as being without Umitation to such specifically recited examples and conditions, 

25 Moreover, all statements herein reciting principles, aspects, and embodiments of the 

invention, as well as specific examples thereof, are intended to encompass both structural 
and functional equivalents thereof Additionally, it is intended that such equivalents 
include both currently known equivalents as well as equivalents developed in the future, 
i.e., any elements developed that perform the same Sanction, regardless of structure, 

30 In the claims hereof any element expressed as a means for performing a specified 

function is intended to encompass any way of performing that function including, for 
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example, a) a combination of circuit elements which perfomis that function or b) 
software in any form, including, therefore, firmware, microcode or the like, combined 
with appropriate circuitry for executing that software to perform the ftmction. The 
invention as defined by such claims resides in the fact that the fimctionalities provided by 

5 the various recited means are combined and brought together in the manner which the 
claims call for. Applicant thus regards any means wliich can provide those fimctionalities 
as equivalent as those shown herein. Many other modifications and applications of the 
principles of the invention will be apparent to those skilled in the art and are 
contemplated by the teachings herein. Accordingly, the scope of the invention is limited 

10 only by the claims. 
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What is claimed is: 

1 . A bridge device for expanding the nurnber of addressable devices that can 
be connected to a communications bus, said devices using a predetermined protocol, said 
device comprising: 

5 at least one parent bus port for coupling at least one host bus master over a parent 

bus, said bus master operable to utilize a layered communication protocol having bridge 
device addressing capabilities and addressing characteristics of said predetermined 
protocol included therein; 

at least one child bus port for coupling to target devices over a child bus, said 

10 target devices adapted to communicate using said predetermined protocol; 

a digital processor coupled to said parent bus port and said child bus port, said 
digital processor operable to implement a protocol translator, said protocol translator 
operable to translate messages in said layered protocol on said parent bus port to said 
predetermined protocol output at said child bus port and to translate messages received at 

15 said child bus port in said predetermined protocol to said layered protocol to be output 
from said child bus port. 

2. The device of claim 1 , wherein said protocol translator is operable to pass 
through a message in said layered protocol onto said child bus to another bridge device 

20 coupled to said child bus. 

3 . The device of Claim 1 , wherein said predetermined protocol is an I C 
protocol. 

25 4. The device of Claim 1 , wherein a message to said bridge device in said 

layered protocol includes a bridge address field and a target device address field. 



5. The device of Claim 1 , wherein said layered protocol includes a read/write 
function indication to said target devices. 

30 
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6. The device of Claim 5, wherein said bridge device returns a layered 
protocol message to said host bus master that includes a message field having data for a 
write command or a read count field for a read commiand. 

5 7. The device of Claim 1 , wherein said protocol translator includes a packet 

parser and dispatch mechanism for separating packets in said layered protocol and 
dispatching packets of said predetermined protocol over child bus. 

8. The device of Claim 1 , wherein a standard format message in said layered 
10 protocol includes a CRC field having a value based on other data included in said 

message, said device further including CRC generator and checker. 

9. The device of Claim 8, wherein an I^C address for said target devices is 
represented in said CRC value. 

15 

1 0. The device of Claim 8, wherein a host bus master can identify 
communications from a specific tm-get device based on a tag field and a CRC value 
returned from said bridge device. 

20 11. The device of Claim 1 , further including a command collision detector for 

determining whether multiple host bus masters have commands pending on said parent 
bus. 

12. The device of Claim 1, further including a special function command 
25 engine for receiving and processing special commands from said host bust master, 

13. The device of Claiml, wherein said bridge device is a slave to said host 
bus master and a master of said child bus. 

30 14. The device of Claim 1 , wherein said bridge device provides isolation 

between said parent bus and said child bus. 
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1 5 . The device of Claim 1 , wherein said bus is a two-wire bus. 

16. A bridge device for interfacing between a host bus master and target 
5 devices coupling to a two-wire electrical bus, said device comprising: 

a first transceiver coupled to said host bus master over a parent bus, said host bus 
master utilizing a first communications protocol; 

a second transceiver coupled to said target devices over a child bus, said target 
devices utilizing a second communications protocol, said first protocol having a bridge 
10 device address field for addressing said bridge devices and a target device address field 
for addressing said target devices coupled to said child bus, where the number of target 
devices addressable by said host bus master is expandable based on the number of bridge 
device coupled thereto; and 

a protocol translator coupled to said first and second transceiver for translating 
15 communications in said first protocol destined for said target devices to said second 
protocol and translating communications in said second protocol destined for said bus 
master to said first protocol. 

1 7. The device of claim 1 6, wherein said protocol translator is operable to 
20 pass through a message in said layered protocol onto said child bus to another bridge 

device coupled to said child bus. 

18. The device of Claim 16, wherein said second protocol is an I^C protocol. 

25 19. The device of Claim 1 6, wherein said protocol translator includes a packet 

parser and dispatch mechanisms for separating packets in said first protocol and 
dispatching packets of said second protocol over child bus. 

20. The device of Claim 1 6, wherein a sbmdard format message in said first 
30 protocol includes a CRC field having a value based on other data included in said 
message, said device further including CRC generator and checker. 
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2 1 . The device of Claim 1 6, ftirther includiing a command collision detector 
for determining whether multiple host bus masters have commands pending on said 
parent bus. 

5 

22. The device of Claiml6, wherein said bridge device is a slave to said host 
bus master and a master of said child bus. 

23. The device of Claim 16, wherein said bridge device provides isolation 
10 between said parent bus and said child bus. 

24. The device of Claim 20, wherein an I^'C address for said target devices is 
represented in said CRC value. 

15 25. The device of Claim 20, wherein a host bus master can identify 

communications from a specific target device based on a tag field and a CRC value 
returned from said bridge device. 

26. A method for expanding the number of addressable devices which use a 
20 given protocol that can be connected to a communications bus, said method comprising: 
providing a bridge device having at least one parent bus port and at least one child 
bus port adapted for coupling, respectively, to a parent bus and a child bus; 

coupling to at least one host bus master to said parent bus, said bus master 
operable to utilize a layered communication protocol having bridge device addressing 
25 capabilities and addressing characteristics of said given protocol included therein; 

coupling to said child bus target devices assigned to said bridge device and 
adapted to communicate using said given protocol; 

translatmg messages in said layered protocol received on said parent bus port to 
said given protocol to be output at said child bus port and translating messages received 
30 at said child bus port in said given protocol to said kyered protocol to be output from 
said child bus port. 



34 



Delmonico-l 



27 . A system comprising : 

at least one host bus master including a digital processor, said host bus master 
operable to utilize a first commxinications protocol for communicating over a parent bus; 
5 and 

at least one bridge device including, 

a first transceiver coupled to said host bus master over said parent bus, 
said host bus master utilizing a first communications protocol; 

a second transceiver coupled to target devices over a child bus, said target 
10 devices utilizing a second commxmications protocol, said first protocol having a 

bridge device address field for addressing said bridge devices and a target device 
address field for addressing said target devices coupled to said child bus; and 

a protocol translator coupled to said first and second transceiver for 
translating communications in said first protocol destined for said target devices 
15 to said second protocol and translating communications in said second protocol 

destined for said bus master to said first protocol. 

28. The system of Claim 27 including at least two bridge devices coupled to 
said parent bus, said host bus master operable to use pairs of said bridge devices to verify 

20 data received from said target devices. 
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ABSRACT 

The present invention is an I^C (inter-IC control) bridge device which implements 
a communication protocol layered on top of a standai'd I^C protocol. The layered 
protocol used by the bridge device is termed the "Layered I^C Protocol" - abbreviated 

5 "LIP". Thus the bridge device is called a "LIP bridge device". The LIP bridge device 
provides I^C address extension, data integrity checking, and fault detection and isolation 
when inserted between an I^C bus master and it's intended target I^C device. Each LIP 
bridge device has at least two attached I^C busses - a parent bus and a child bus. The LIP 
bridge operates as a slave on its parent bus, and a master of its child bus. The Layered 

10 f C protocol is specified to operate on a bus between one or more bus masters and the 
parent bus of one or more LIP bridge devices. The child bus is used for attaching 
multiple I^C devices and/or one or more LIP bridge devices. In an exemplary 
implementation, the LIP bridge device is constructed using a microcontroller to create a 
LIP bridge device with one parent and one child I^C bus port and a group of LIP bridge 

15 configuration pins. The parent bus traffic to a given LIP bridge device consists entirely 
of LIP packets, and the child bus traffic consists of standard I^C packets to communicate 
with standard child bus I^C devices. The child bus traffic may also consist of LIP packets 
to communicate with LIP bridges attached to the child bus. By design, the LIP packets 
and standard I^C transactions do not interfere with one another. The LIP bridge device 

20 interprets LIP command packets from a bus master and translates them into the intended 
I^C data stream that is then broadcast over the child bus. Likewise, data Jfrom the child 
bus is used to create LIP packets that are returned to the proper bus master. The use of 
LIP packets on a given I^C bus provides an extra level of I^C addressing. 
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Figure 2 - LBP Bridge Internal Block Diagram 
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Figure 3: Typical Usage of LIP Bridge 
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The LIP Address / Function encoding within the four byte LIP packet is as follows: 
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The Child Address / Function encoding is as follows: 
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15 Status Byte Register Organization 
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Table 8 

Key to Symbols 
Symbol Meaning 



S 

P 

A 

A 

LA 
CA 

W 

R 
CRC 
Data 
Count 
Fnc(x) 



PC bus start condition 
PC bus stop condition 
Acknowledge 
No-Acknowledge 
LIP address 
Child bus address 

R/l W bit within address field is set for WRITE 
R/! W bit within address field is set for READ 
CRC byte 

Data byte 
Read count 

Special function command "x" - where x is the function's hex code 
Gray shade indicates data sent from host bus master to LIP bridge 
White indicates data sent from LIP bridge to host bus master 
Zero or more instances of the preceding transaiction. 



5 Host bus master to LEP One Byte Child Bus Write 
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Host bus master to LIP Multi-Byte Write 
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Special Function Action Neither Requiring Nor Returning Data 
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Where n=Ofor host bus masterO, n^l for host bus master 1 & "x" is the desired hex 
command code. 
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Special Function Action Returning Data 



Where n=Ofor host bus masterO, n^lfor host bus master 1 & "x" is the desired hex 
command code. 
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FIG. 14 



Special Function Action Requiring Data 



FIG. 15 



Host bus master Child Bus Read Via LIP Bridge Action 




Read data tag A 



Data 



Data M CRC 




FIG. 16 
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RB3 



PIN# 


Label 


Function 


2 


IMCLR 


!partner_reset_in -- Active low input for reset from partner LDP bridge 
(Also VPP pin for in circuit progiamming) 


3 


RAO 


ipartner reset out - Active low output to reset partner LEP bridge 


20 


RC3 


LIP elk - LIP bus serial clock in 


25 


RC4 


LIP data -- LIP bus serial data in/out (bidirectional) 


27 


RC6 


Child elk -- child bus clock output 


29 


RC7 


Child data - child bus data hi/out (bidirectional) 


37 


RBI 


LIP addr parity - parity bit for LIP address (strap to make odd parity) 


38 


RB2 


LIP addrO - bit 0 to strap LIP PC address 


39 


RB3 


LIP addrl ~ bit 1 to strap LIP PC address 


41 


RB4 


LIP addr2 - bit 2 to strap LIP PC address 


42 


RB5 


LIP addr3 - bit 3 to strap LDP PC address 


4 


RAl 


LIP addr4 - bit 4 to strap LEP PC address 


5 


RA2 


LIP addr5 ~ bit 5 to strap LIP PC address 


43 


RB6 


In circuit programming clock 


44 


RB7 


In circuit programming data 


6 


RA3 


Child bus busy out -active low open collector output when this LIP bridge owns child bus 
(needs a IK pull up to Vdd). 


36 


RBO 


Child bus busy in -active low input when partner LIP bridge owns child bus 
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MCLR/Vpp 
BAD 
RAt 
RA2 
RAa 

RA4/TGCKI 
RA5/SS 
V8S 

0SC1/CLKIN 
OSG2/CLKOUT 
BC0/T1OSO/T10K1 
RC1,'^10SI 
RC2/CCP1 
RC3/SCK/SCL 






RS7 




BBS 




R85 




RS4 




BS3 




Be2 




R81 




RBO/tNT 




Vdd 




Vss 




RC7 




RC6 




RC6/SDO 



RC4/S0i/BDA 



I? 



PIN# 


Label 


Function 


1 


IMCLR 


!partner_reset_in - Active low input for reset from partner LIP bridge 
(Also VPP pin for in circuit programming) 


2 


RAO 


Ipartner reset out - Active low output to reset partner LIP bridge 


14 


RC3 


LIP elk - LIP bus serial clock in 


15 


RC4 


LIP data - LIP bus serial data in/out (bidirectional) 


17 


RC6 


child_clk " child bus clock output 


18 


RC7 


cMd_data - child bus data in/out (bidirectional) 


22 


RBI 


LIP addr parity - parity bit for LIP address (strap to make odd parity) 


23 


RB2 


LIP_addrO - bit 0 to strap LEP PC address 


24 


RB3 


LIP_addrl - bit 1 to strap LIP PC address 


25 


RB4 


LIP addr2 - bit 2 to strap LIP PC address 


26 


RB5 


LIP^addr3 - bit 3 to stiap LIP PC address 


3 


RAl 


LIP_addr4 - bit 4 to strap LIP PC address 


4 


RA2 


LIP_addr5 - bit 5 to strap LIP PC address 


27 


RB6 


In circuit programming clock 


28 


RB7 


In circuit programnung data 


5 


RA3 


chi]d_bus_busy_out -active low output when this LIP bridge owns child bus (needs a IK pull 
up to Vdd). 


21 


RBO 


child_bus_busy Jn -active low input when partner LIP bridge owns child bus 
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Level 1 Data Flow Diagram 



LIP_Bus 
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Firmware I2C Data Flows 



Delmonico-1 




De\inoonico I 




•rV ^^'^^ 



ft. 



tA;;(/ /iJ'^/ 



J J. Delmonico 1 



IN THE UNITED STATES 
PATENT AND TRADEMAF^K OFFICE 

Declaration and Power of Attorney 



As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my name. 

I believe I am an original, first and sole inventor of the subject matter which is claimed 
and for which a patent is sought on the invention entitled EXPANSION BRIDGE APPARATUS 
AND METHOD FOR AN I^C BUS the specification of which is attached hereto. 

I hereby state that I have reviewed and understand the contents of the above identified 
specification, including the claims, as amended by an amendment, if any, specifically referred to 
in this oath or declaration. 

I acknowledge the duty to disclose all information known to me which is material to 
patentability as defined in Title 37, Code of Federal Regulations, 1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code, 119 of any 
foreign application(s) for patent or inventor's certificate listed below and have also identified 
below any foreign application for patent or inventor*s certificate having a filing date before that of 
the application on which priority is claimed: 

None 

I hereby claim the benefit under Title 35, United States Code, 120 of any United States 
application(s) listed below and, insofar as the subject matter of each of the claims of this 
application is not disclosed in the prior United States application in the manner provided by the 
first paragraph of Title 35, United States Code, 112, I acknowledge the duty to disclose all 
information known to me to be material to patentability as defined in Title 37, Code of Federal 
Regulations, 1.56 which became available between the filing date of the prior application and 
the national or PCT international filing date of this application: 

None 

I hereby declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of the application or any 
patent issued thereon. 

I hereby appoint the following attorney(s) with full power of substitution and revocation, 
to prosecute said application, to make alterations and amendments therein, to receive the 
patent, and to transact all business in the Patent and Trademark Office connected therewith: 
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Thomas J. Bean 
Lester H. Birnbaum 
Richard J. Botos 
Jeffery J. Brosemer 
Kenneth M. Brown 
Donald P. Dinella 
Martin 1. Finston 
William S. Francos 
Barry H. Freedman 
Julio A. Garceran 
Jimmy Goo 
Anthony Grillo 
Stephen M. Gurey 
John M. Harman 
Matthew J. Hodulik 
Michael B. Johannesen 
Mark A. Kurisko 
Irena Lager 
John B. Maclntyre 
Christopher N. Malvone 
John F. McCabe 
Scott W. McLellan 
Martin G. Meder 
John C. Moran 
Michael A. Morra 
Gregory J. Murgia 
Claude R. Narcisse 
Joseph J. Opalach 
Neil R. Ormos 
Jack R. Penrod 
Gregory C. Ranieri 
Scott J. Rittman 
Ferdinand M. Romano 
Eugene J. Rosenthal 
Bruce S. Schneider 
Ronald D. Slusky 
David L. Smith 
Ozer M. N. Teitelbaum 
John P. Veschi 
David Volejnicek 
Charles L. Warren 
Eli Weiss 



(Reg. No. 44528) 
(Reg. No. 25830) 
(Reg. No. 32016) 
(Reg. No. 36096) 
(Reg. No. 37590) 
(Reg. No. 39961) 
(Reg. No. 31613) 
(Reg. No. 38456) 
(Reg. No. 26166) 
(Reg. No. 37138) 
(Reg. No. 36528) 
(Reg. No. 36535) 
(Reg. No. 27336) 
(Reg. No. 38173) 
(Reg. No. 36164) 
(Reg. No. 35557) 
(Reg. No. 38944) 
(Reg. No. 39260) 
(Reg. No. 41170) 
(Reg. No. 34866) 
(Reg. No. 42854) 
(Reg. No. 30776) 
(Reg. No. 34674) 
(Reg. No. 30782) 
(Reg. No. 28975) 
(Reg. No. 41209) 
(Reg. No. 38979) 
(Reg. No. 36229) 
(Reg. No. 35309) 
(Reg. No. 31864) 
(Reg. No. 29695) 
(Reg. No. 39010) 
(Reg. No. 32752) 
(Reg. No. 36658) 
(Reg. No. 27949) 
(Reg. No. 26585) 
(Reg. No. 30592) 
(Reg. No. 36698) 
(Reg. No. 39058) 
(Reg. No. 29355) 
(Reg. No. 27407) 
(Reg. No. 17765) 



Please address all correspondence to the Docket Administrator (Rm. 3C-512), Lucent 
Technologies Inc., 600 Mountain Avenue, P. 0. Box 636, Murray Hill, New Jersey 07974-( 
Telephone calls should be made to Matthew J Hodulik by dialing 732-949-9742. 
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Full name of sole inventor: James J Delmonico 



Inventor's ^mnaiuvB ^^A^^^ ^^4^#?g6^> Date_^4^^^ 
Residence: Clinton, Worcester County, Massachusetts 
Citizenship: US 

Post Office Address: 6 Bear Path 

Clinton, Massachusetts, 01510 



